In the present context the expression “network equipment” means any type of hardware, for example, servers, terminals, switches, routers, or concentrators, capable of exchanging data, in particular management data, with the network management system (NMS) of the network to which it belongs in accordance with a network management protocol. The network management protocol may be the Simple Network Management Protocol (SNMP) of RFC 2571-2580, for example, used in particular in ADSL networks, the TL1 protocol used in particular in SONET networks, the Q3 protocol used in particular in SDH networks, or the CLI and CORBA protocols.
In some communications networks, the network equipments (network elements) are managed as a function of a policy defined by policy rules.
In the present context, the expression “policy rule” means a rule of the type “if <condition> then <action>”.
These policy rules define traffic processing operations associated with services that the network equipments must carry out. They are first worked out by the network operator (or supervisor), as a function of the equipments that constitute the network and service level agreements (SLA) entered into with its customers, and are then sent to a policy server belonging to the NMS which validates them.
The network equipments are unable to understand policy rules validated and delivered by the policy server, which must therefore be converted into configuration commands, for example command line interface (CLI) commands.
This kind of conversion depends not only on the type of network equipment but also on the management protocol that it uses for dialogue with the NMS, to be more precise with its element management system (EMS), which serves as its dialogue interface. Because the policy server does not know either the equipment types or their management protocols, it cannot effect the conversions in a centralized manner.
To solve this problem, there is between the management server and each network equipment what is known to the person skilled in the art as a policy enforcement point (PEP). Each PEP is dedicated to converting primary data delivered by the policy server and defining validated policy rules into configuration commands specifically adapted to the management protocol of the associated network equipment.
A specific PEP must therefore be designed for each network equipment and each equipment must be equipped with the associated PEP, which compromises the flexibility of the management architecture based on policy rules and necessitates costly human intervention.
Moreover, conflicts may arise between policy rules instituted in the same network equipment because of the manner in which policy rules are sent out.
It is undoubtedly possible, using a tool such as Orchestream, to display on a screen all of the policy rules that have been instituted in a network equipment, but this type of tool does not provide conjoint access to the configuration parameters of the equipment induced by said rules.
It is also possible, using a tool such as an EMS browser, to display on a screen the configuration parameters of a network equipment induced by the policy rules that it has instituted, but this type of tool does not provide conjoint access to the instituted policy rules.
In other words, the existing tools can only very partially assist operators to diagnose conflicts within the equipments that constitute their networks.